Subscriber authentication using a user device-generated security code

ABSTRACT

A device receives an indication that a security code is to be generated; generates the security code based on the indication; generate a message that includes the security code and an identifier associated with a subscriber of the device; outputs the message using the first protocol; encodes the security code based on outputting the message; and outputs a request to access the service. The request is outputted using a second protocol, and includes the encoded security code and the identifier. The device receives a notification that indicates whether the subscriber is authenticated based on the identifier, the security code, and the encoded security code; and accesses the service when the notification indicates that the subscriber is authenticated.

BACKGROUND

User devices perform an increasing variety of tasks that allow users tomake and receive calls and/or access services (e.g., to send and receivemessages, download and play audio and/or video content, make electronicpurchases, communicate via social networking, etc.) via a network, suchas the Internet. The user devices usually provide, to the network, logincredentials (e.g., usernames, passwords, personal identification numbers(PINs), etc.), associated with the users, that enable the users to beauthenticated prior to being granted access to the services.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a diagram of an example authentication scheme to authenticatea subscriber;

FIG. 1B is a diagram of an overview of an example implementationdescribed herein;

FIG. 2 is a diagram of an example environment in which systems and/ormethods described herein may be implemented;

FIG. 3 is a diagram of example components of one or more devices of FIG.2;

FIG. 4 is a flow chart of an example process for authenticating a userdevice based on a request for an application;

FIG. 5 is a flow chart of an example process for authenticating asubscriber based on a security code generated by a user device;

FIG. 6 is a diagram of an example data structure that storesauthentication information associated with a subscriber;

FIG. 7 is a flow chart of an example process for authenticating asubscriber, using a security code, in response to a request to access aservice; and

FIG. 8 is a diagram of an example signal flow between devices of anexample portion of the environment of FIG. 2.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements.

Systems and/or methods, described herein, may enable a server device,such as an application server, to authenticate a subscriber based on anidentifier associated with the subscriber and/or a security code (e.g.,that includes a string of characters, numbers, etc.) that is generatedby a user device. The systems and/or methods may enable the user deviceto generate the security code and to provide the security code and theidentifier to the application server via an out-of-band message. Theout-of-band message may be provided based on a message protocol (e.g., ashort message service (SMS) mobile originating (MO) message protocol, asignal system seven (SS7) protocol, an instant message protocol, and/orsome other message protocol). The user device may also, oralternatively, provide a request for the service (e.g., a hypertexttransfer protocol (HTTP) request, a short message peer-to-peer (SMPP)request, a session initiation protocol (SIP) request, etc.), to theapplication server, that includes an encoded version of the securitycode and/or the identifier. Providing the security code, to theapplication server, via the out-of-band message and the encoded versionvia the request, may enable the application server to authenticate thesubscriber based on the security code and/or the identifier.

Authenticating the subscriber using a user device-generated securitycode may enable an application server to authenticate the subscriberwithout instructing the subscriber to provide login credentials (e.g., ausername, a password, a personal identification number (PIN), etc.)which may improve the subscriber experience. Additionally, oralternatively, the user device-generated security code may enabledifferent types of user devices, such as those that do not permitapplications to access out-of-band messages (e.g., that includeapplication server-generated security codes) received from anapplication server (e.g., such as messages based on a SMS mobileterminating (MT) message protocol), to authenticate the subscriber.Additionally, or alternatively, using the encoded version of thesecurity code may not permit applications, installed on the user device,to use the security code in an unauthorized manner, which may improve alevel of security associated with the user device-generated securitycode relative to a security code that is generated be the applicationserver.

FIG. 1A is a diagram of an example authentication scheme 100(hereinafter referred to as “scheme 100”) to authenticate a subscriber.As illustrated in FIG. 1A, scheme 100 may include a user deviceassociated with a subscriber that desires to obtain a service. Theservice may, for example, correspond to downloading an application,receiving audio and/or video content, accessing a website, obtaining adocument, making an electronic purchase, etc. The subscriber may causethe user device to provide, to an applications server, a request toaccess the service (e.g., an access request). The request may includesubscriber information associated with the subscriber (e.g., a username,a password, a PIN, etc.).

The application server may receive the request and may perform a lookupoperation, using the subscriber information, by accessing a databasethat stores subscriber information associated with the subscriber and/orother subscribers. When the received subscriber information matchessubscriber information stored within the database, the applicationserver may, in one example, generate a security code and may store thesecurity code in the database. The application server may provide, tothe user device, a message that includes the security code.Additionally, or alternatively, the application server may not generatethe security code, but may authenticate the subscriber when the receivedsubscriber information matches the stored subscriber information. Inthis example, the authentication server may not authenticate thesubscriber when the received subscriber information does not match thestored subscriber information.

The user device may receive the message and may provide, to theapplication server, another request to obtain the service (e.g., aservice request that includes the security code). The application servermay obtain the security code from the other request and may performanother lookup operation based on the security code. When the receivedsecurity code matches a security code, stored within the database, theapplication server may authenticate the subscriber and may provide, tothe user device, a notification indicating that the user device has beengranted access to the service. When the received security code does notmatch a stored security code, the application server may notauthenticate the subscriber and may provide, to the user device, anotification that indicates that the service cannot be accessed.

FIG. 1B is a diagram of an overview 110 of an example implementationdescribed herein. As illustrated in FIG. 1B, overview 110 may include auser device associated with a subscriber that desires to obtain aservice that is provided by an application server. The subscriber may,for example, instruct the user device to access a service that isprovided by the application server. Based on the instruction, the userdevice may generate a security code and may provide an out-of-bandmessage, that includes the security code and an identifier associatedwith the subscriber (e.g., a mobile directory number, etc.), to theapplication server. The out-of-band message may, for example, be basedon a particular message protocol (e.g., an instant message protocol, anSMS MO protocol, a SS7 protocol, etc.). The application server mayreceive the out-of-band message and may store the security code and theidentifier in a database.

The user device may also, or alternatively, use a mechanism to encodethe security code to create an encoded security code. The user devicemay provide, to the application server, a request (e.g., an HTTPrequest, a SMPP request, a SIP request, etc.) to obtain the service thatincludes the encoded security code and the identifier. The applicationserver may receive the request and may use a decoding mechanism,associated with the identifier, to decode the encoded security code. Theapplication server may determine whether the received identifier matchesan identifier stored in the database. When the received identifiermatches a stored identifier, the application server may determinewhether the decoded security code matches a stored security codeassociated with the stored identifier. When the decoded security codematches the stored security code, the application server mayauthenticate the subscriber and may provide, to the user device, anotification indicating that the user device is granted access to theservice. When the decoded security code does not match the storedsecurity code, the application server may not authenticate thesubscriber and may provide, to the user device, a notificationindicating that the service cannot be accessed.

Authenticating the subscriber based on the user device-generatedsecurity code may enable the subscriber to be authenticated withoutproviding a username, a password, a PIN, etc. each time a service isaccessed, which may improve the user experience. Additionally, oralternatively, authenticating the subscriber based on the userdevice-generate security code may simplify signaling and/or reduceresource usage compared to authenticating the subscriber based on theusername, the password, the PIN, etc.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods described herein may be implemented. As shown in FIG. 2,environment 200 may include a user device 210, a base station 220, aserving gateway 230 (hereinafter referred to as “SGW 230”), a mobilitymanagement entity device 235 (hereinafter referred to as “MME 235”), apacket data network (PDN) gateway 240 (hereinafter referred to as “PGW240”), a home subscriber server (HSS)/authentication, authorization,accounting (AAA) server 250 (hereinafter referred to as an “HSS/AAAserver 250”), a message server 260, an application server 270, adatabase 280, a service provider 285, and a network 290.

The quantity of devices and/or networks, illustrated in FIG. 2, isprovided for explanatory purposes only. In practice, there may beadditional devices and/or networks; fewer devices and/or networks;different devices and/or networks; or differently arranged devicesand/or networks than illustrated in FIG. 2. Alternatively, oradditionally, one or more of the devices of environment 200 may performone or more functions described as being performed by another one ormore of the devices of environment 200. Devices of environment 200 mayinterconnect via wired connections, wireless connections, or acombination of wired and wireless connections.

Environment 200 may include an evolved packet system (EPS) that includesa long term evolution (LTE) network and/or an evolved packet core (EPC)network that operate based on a third generation partnership project(3GPP) wireless communication standard. The LTE network may be a radioaccess network (RAN) that includes one or more base stations 220, someor all of which, take the form of an eNodeB (eNB) via which user device210 communicates with the EPC network. The EPC network may include oneor more SGWs 230, MMEs 235, and/or PGWs 240, and may enable user device210 to communicate with network 290 and/or an Internet protocol (IP)multimedia subsystem (IMS) core network. The IMS core network mayinclude HSS/AAA server 250 and may manage authentication, sessioninitiation, account information, a user profile, etc. associated withuser device 210.

User device 210 may include any computation and communication device,such as a wireless mobile communication device that is capable ofcommunicating with base station 220 and/or network 290. For example,user device 210 may include a radiotelephone; a personal communicationssystem (PCS) terminal (e.g., that may combine a cellular radiotelephonewith data processing and data communications capabilities); a personaldigital assistant (PDA) (e.g., that can include a radiotelephone, apager, Internet/intranet access, etc.); a smart phone; a laptopcomputer; a tablet computer; a camera; a personal gaming system, oranother type of mobile computation and communication device. User device210 may send traffic to and/or receive traffic from network 290 viasignal bearers, such as base station 220, SGW 230 and/or PGW 240. Userdevice 210 may use an application to generate a security code and mayuse the security code to obtain a service from application server 270.User device 210 may, for example, provide the security code toapplication server 270 indirectly, via message server 260, as anout-of-band message. In one example, user device 210 may provide thesecurity code via the out-of-band message based on a message protocol(e.g., an SMS MO protocol, a SS7 protocol, and/or some other messageprotocol). User device 210 may also, or alternatively, use a mechanismto encode the security code (e.g., using a hash function, acryptographic hash function, an encryption function, and/or some othermathematical function). User device 210 may provide, to applicationserver 270, a request for the service. The request may include theencoded security code and/or the identifier.

Base station 220 may include one or more network devices that receive,process, and/or transmit traffic, such as calls, audio, video, text,and/or other data, destined for and/or received from user device 210. Inone example, base station 2 20 may be an eNB device and may be part ofthe LTE network. Additionally, or alternatively, one or more other basestations 220 may be associated with a RAN that is not associated withthe LTE network (e.g., a wireless hot spot, a wireless access point,etc.). Base station 220 may receive traffic from and/or send traffic tonetwork 290 via SGW 230 and PGW 240. Base station 220 may send trafficto and/or receive traffic from user device 210 via an air interface.

SGW 230 may include one or more network devices that gather, process,search, store, and/or provide information in a manner described herein.For example, SGW 230 may include a gateway, a router, a modem, a switch,a firewall, a network interface card (NIC), a hub, a bridge, a proxyserver, an optical add-drop multiplexer (OADM), or some other type ofdevice that processes and/or transfers traffic. SGW 230 may, forexample, aggregate traffic received from one or more base stations 220and may send the aggregated traffic to network 290 via PGW 240.

MME 235 may include one or more computation and communication devicesthat gather, process, search, store, and/or provide information in amanner described herein. For example, MME 235 may perform operations toregister user device 210 with the EPS, to establish signal bearersassociated with a session with user device 210, to handoff user device210 from the EPS to another network, to handoff user device 210 from theother network to the EPS, and/or to perform other operations. MME 235may perform policing operations on traffic destined for and/or receivedfrom user device 210.

PGW 240 may include one or more network devices, or other types ofcomputation and communication devices, that gather, process, search,store, and/or provide information in a manner described herein. Forexample, PGW 240 may include a gateway, a router, a modem, a switch, afirewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some othertype of device that processes and/or transfers traffic. PGW 240 mayaggregate traffic received from one or more SGWs 230, etc. and may sendthe aggregated traffic to network 290. PGW 240 may also, oralternatively, receive traffic from network 290 and may send the traffictoward user device 210 via SGW 230 and/or base station 220.

HSS/AAA server 250 may include one or more server devices, or othertypes of devices, that gather, process, search, store, and/or provideinformation in a manner described herein. For example, HSS/AAA server250 may manage, update, and/or store, in a memory associated withHSS/AAA server 250, profile information associated with a subscriber.The profile information may identify applications and/or services thatare permitted for and/or accessible by the subscriber; a MDN associatedwith the subscriber; bandwidth or data rate thresholds associated withthe applications and/or services; information associated with thesubscriber (e.g., a username, a password, a PIN, etc.); rateinformation; minutes allowed for a subscriber; and/or other information.The subscriber may be associated with user device 210 and/or one or moreother user devices 210. Additionally, or alternatively, HSS/AAA server250 may perform authentication, authorization, and/or accounting (AAA)operations associated with the subscriber and/or a communication sessionwith user device 210.

Message server 260 may include one or more computation and communicationdevices that gather, process, search, store, and/or provide informationin a manner described herein. In an example implementation, messageserver 260 may correspond to a short message service center (SMSC)server. Message server 260 may, for example, process out-of-bandmessages. In one example, message server 260 may receive, from userdevice 210 and via base station 220, an out-of-band message based on amessage protocol (e.g., a SMS protocol, a SS7 protocol, or some othermessage protocol) that includes a security code and/or an identifierassociated with a subscriber (e.g., a MDN and/or some other identifier).Message server 260 may forward the out-of-band message to applicationserver 270. Message server 260 may, for example, forward the out-of-bandmessage in a manner that prevents the out-of-band message from beingrouted to another network (e.g., via network 290) and/or accessed viaanother network. In one example, message server 260 may use a short codeassociated with application server 270 (e.g., that includes fewercharacters or digits than a long code, such as a landline telephonenumber, an MDN, etc.), and/or some other format, to forward theout-of-band message.

Application server 270 may include one or more computation andcommunication devices that gather, process, search, store, and/orprovide information in a manner described herein. Application server 270may register user device 210 and may provide an application to userdevice 210 as a result of registering user device 210. In one example,application server 270 may communicate with HSS/AAA server 250 toauthenticate user device 210 prior to registering user device 210.Additionally, or alternatively, application server 270 may, for example,receive an out-of-band message from message server 260 and may store anidentifier and/or a security code in database 280. Application server270 may receive, from user device 210 and via base station 220, arequest to access a service. Application server 270 may obtain, from therequest, an encoded security code and/or an identifier associated withthe subscriber. Application server 270 may identify a decoding mechanismassociated with the identifier and may use the decoding mechanism todecode the encoded security code. Application server 270 may use theidentifier to perform a lookup operation, within database 280, toidentify a stored security code. Application server 270 may authenticatethe subscriber when the stored security code matches the decodedsecurity code. When the subscriber is authenticated, application server270 may provide the service to user device 210. Additionally, oralternatively, applications server 270 may provide an authenticationservice to service provider 285. For example, application server 270 mayprovide a notification, to service provider 285, that indicates whetherthe subscriber is authenticated when the service is to be provided, touser device 210, by service provider 285.

Database 280 may include one or more devices that store information usedby application server 270 to perform operations described herein.Database 280 may, for example, store information used to authenticatesubscribers, such as session identifiers that identify sessionsassociated with user devices 210, identifiers associated withsubscribers (e.g., MDNs and/or other identifiers), security codes, etc.Database 280 may also, or alternatively, store a lookup table thatassociates a security code with an identifier for each of the sessions.

Service provider 285 may include one or more server devices, or othertypes of computation and communication devices, that provide content.For example, service provider 285 may host a website that can beaccessed, by user device 210, to receive a service. The service may, forexample, correspond to content (e.g., applications, web pages, video,audio, images, games, advertising content, text, data, and/or somecombination thereof), a messaging service (e.g., email, instant message,etc.), a banking service, an electronic sales transaction service, etc.Service provider 285 may provide the content and/or service to userdevice 210 when application server 270 indicates that a subscriber, ofuser device 210, is authenticated.

Network 290 may include one or more wired and/or wireless networks. Forexample, network 290 may include a cellular network, a public landmobile network (PLMN), a second generation (2G) network, a thirdgeneration (3G) network, a fourth generation (4G) network, a fifthgeneration (5G) network, and/or another network. Additionally, oralternatively, network 290 may include a wide area network (WAN), ametropolitan area network (MAN), a telephone network (e.g., the PublicSwitched Telephone Network (PSTN)), an ad hoc network, an intranet, theInternet, a fiber optic-based network, and/or a combination of these orother types of networks.

FIG. 3 is a diagram of example components of a device 300. Device 300may correspond to user device 210, SGW 230, MME 235, PGW 240, HSS/AAAserver 250, message server 260, application server 270, and/or serviceprovider 285. Alternatively, or additionally, each of user device 210,SGW 230, MME 235, PGW 240, HSS/AAA server 250, message server 260,application server 270, and/or service provider 285 may include one ormore devices 300 and/or one or more components of device 300.

Device 300 may include a bus 310, a processor 320, a memory 330, aninput component 340, an output component 350, and a communicationinterface 360. Although FIG. 3 shows example components of device 300,in other implementations, device 300 may contain fewer components,additional components, different components, or differently arrangedcomponents than depicted in FIG. 3. For example, device 300 may includeone or more switch fabrics instead of, or in addition to, bus 310.Additionally, or alternatively, one or more components of device 300 mayperform one or more tasks described as being performed by one or moreother components of device 300.

Bus 310 may include a path that permits communication among thecomponents of device 300. Processor 320 may include a processor, amicroprocessor, or processing logic that may interpret and executeinstructions. Memory 330 may include any type of dynamic storage devicethat may store information and instructions, for execution by processor320, and/or any type of non-volatile storage device that may storeinformation for use by processor 320.

Input component 340 may include a mechanism that permits a user to inputinformation to device 300, such as a keyboard, a keypad, a button, aswitch, etc. Output component 350 may include a mechanism that outputsinformation to the user, such as a display, a speaker, one or more lightemitting diodes (LEDs), etc. Communication interface 360 may include anytransceiver-like mechanism that enables device 300 to communicate withother devices and/or systems via wireless communications, wiredcommunications, or a combination of wireless and wired communications.For example, communication interface 360 may include mechanisms forcommunicating with another device or system via a network, such asnetwork 290. Alternatively, or additionally, communication interface 360may be a logical component that includes input and output ports, inputand output systems, and/or other input and output components thatfacilitate the transmission of data to other devices.

Device 300 may perform certain operations in response to processing unit320 executing software instructions contained in a computer-readablemedium, such as memory 330. A computer-readable medium may be defined asa non-transitory memory device. A memory device may include space withina single physical memory device or spread across multiple physicalmemory devices. The software instructions may be read into memory 330from another computer-readable medium or from another device. Thesoftware instructions contained in memory 330 may cause processor 320 toperform processes described herein. Alternatively, hardwired circuitrymay be used in place of or in combination with software instructions toimplement processes described herein. Thus, s described herein are notlimited to any specific combination of hardware circuitry and software.

Although FIG. 3 shows example components of device 300, in otherimplementations, device 300 may include fewer components, differentcomponents, differently arranged components, or additional componentsthan depicted in FIG. 3. Alternatively, or additionally, one or morecomponents of device 300 may perform one or more other tasks describedas being performed by one or more other components of device 300.

FIG. 4 is a flow chart of an example process 400 for authenticating userdevice 210 based on a request for a security application. In an exampleimplementation, process 400 may be performed by application server 270.Additionally, or alternatively, some or all of process 400 may beperformed by a device or collection of devices separate from, or incombination with, application server 270.

As shown in FIG. 4, process 400 may include receiving, from a userdevice, a request for a security application (block 405) and obtaining,based on the request, information associated with the user device (block410). For example, a subscriber, associated with user device 210, mayinstruct user device 210 to obtain a security application that can beused to generate a security code that may be used to access servicesfrom a network. User device 210 may, based on the instruction, provide arequest for the security application to application server 270.

Application server 270 may receive the request and may obtain, from therequest, information associated with user device 210, such as a deviceidentifier associated with user device 210 (e.g., an internationalmobile equipment identity (IMEI), an electronic serial number (ESN), amobile equipment identifier (MEID), etc.); and/or an address (e.g., anInternet protocol (IP) address, a media access control (MAC) address,etc.). Additionally, or alternatively, application server 270 mayobtain, from the request, information associated with the subscriber,such as a subscriber identifier (e.g., a MDN, a subscriber identitymodule (SIM) uniform resource identifier (URI), a mobile identificationnumber (MIN), an international mobile subscriber identity (IMSI), amobile subscriber integrated services digital network (MSISDN)identifier, a national access identifier (NAI), etc.), etc. In oneexample, application server 270 may communicate with user device 210 toobtain other information associated with the subscriber (e.g., ausername, a password, a PIN, etc.).

As also shown in FIG. 4, process 400 may include communicating with aserver device to determine whether to authenticate the user deviceand/or a subscriber (block 415). For example, application server 270 maycommunicate with HSS/AAA server 250 to authenticate user device 210based on the information, associated with the user device 210, obtainedfrom the request. Additionally, or alternatively, application server 270may communicate with HSS/AAA server 250 to authenticate the subscriberbased on the information associated with the subscriber and/or the otherinformation associated with the subscriber.

HSS/AAA server 250 may determine whether to authenticate user device 210based on whether the information associated with user device 210,matches information, associated with user device 210, stored withinHSS/AAA server 250. Additionally, or alternatively, HSS/AAA server 250may determine whether to authenticate the subscriber based on whetherthe information associated with the subscriber, received as a result ofthe communication, matches information associated with the subscriberstored within the memory.

As further shown in FIG. 4, if the user device is not authenticated(block 420—NO), process 400 may include providing a notificationindicating that the application cannot be provided to the user device(block 425). For example, when the received information, associated withuser device 210, does not match the stored information, associated withuser device 210 (e.g., a received MAC address does not match a storedMAC address, etc.), HSS/AAA server 250 may not authenticate user device210 and/or may provide, to application server 270, a notificationindicating that user device 210 is not authenticated.

Additionally, or alternatively, when the received information,associated with the subscriber, does not match the stored information,associated with the subscriber (e.g., a received MDN does not match astored MDN; a received password does not match a stored password; etc.),HSS/AAA server 250 may not authenticate the subscriber and/or mayprovide, to application server 270, a notification indicating that thesubscriber is not authenticated.

When user device 210 and/or the subscriber are not authenticated,application server 270 may not provide the security application to userdevice 210. In one example, application server 270 may provide, to userdevice 210, a notification indicating that the security applicationcannot be provided to the user device 210. The notification may also, oralternatively, indicate that user device 210 and/or the subscriber arenot authenticated.

As yet further shown in FIG. 4, if the user device is authenticated(block 420—YES), process 400 may include providing an application to theuser device (block 430). For example, when the received information,associated with user device 210, matches the stored information,associated with user device 210, HSS/AAA server 250 may authenticateuser device 210 and/or may provide, to application server 270, anotification indicating that user device 210 is authenticated.

Additionally, or alternatively, when the received information,associated with the subscriber, matches the stored information,associated with the subscriber, HSS/AAA server 250 may authenticate thesubscriber and/or may provide, to application server 270, a notificationindicating that the subscriber is authenticated.

When user device 210 and the subscriber are authenticated, applicationserver 270 may provide the security application to user device 210. Thesecurity application may, for example, include a mechanism that can beused, by user device 210, to generate a security code. The securityapplication may also, or alternatively, include an encoding mechanismthat can be used to encode the security code. The security mechanismmay, for example, correspond to a hash function, a cryptographic hashfunction, an encryption function, and/or some other mathematicalfunction that can be used to encode the security code. Additionally, oralternatively, the security mechanism may include a shared key. Theshared key may be used, by user device 210, to encode the security code.Application server 270 may store a copy of the shared key that can beused to decode an encoded security code received from user device 210.

User device 210 may receive the security application and may store thesecurity application on user device 210. Alternatively, or additionally,user device 210 may provide the security application for display to thesubscriber.

FIG. 5 is a flow chart of an example process 500 for authenticating asubscriber, based on a security code generated by a user device. In oneexample implementation, process 500 may be performed by user device 210.Additionally, or alternatively, some or all of process 500 may beperformed by a device or collection of devices separate from, or incombination with, user device 210.

As shown in FIG. 5, process 500 may include receiving an instruction toaccess a service (block 505) and generating a security code based on theinstruction (block 510). For example, a subscriber may desire to accessa service and may cause user device 210 to power up. User device 210may, as a result of powering up, automatically execute a securityapplication, previously received from application server 270 in a mannersimilar to that described above in FIG. 4, to generate a security code.

Additionally, or alternatively, the subscriber may cause user device 210to open application, hosted by user device 210, that is to be used toaccess the service (e.g., a browser, an email application, a game, asocial networking application, etc.). Opening the application may causeuser device 210 to automatically execute the security application togenerate the security code. Additionally, or alternatively, thesubscriber may manually cause the security code to be generated byselecting an icon, associated with the security application, beingdisplayed on user device 210. Selecting the icon may cause user device210 to open the security application and to execute the securityapplication to generate the security code.

The security code may be generated in a number of ways. In one example,the security application, when executed, may generate a random value onwhich the security code is based. Additionally, or alternatively, thesecurity application may use a mechanism (e.g., a hash function and/orsome other mathematical function) to encode the random value and theencoded random value may be the security code. Additionally, oralternatively, the security application may use the mechanism togenerate the security code based on the random value and an identifierassociated with the subscriber (e.g., MDN, etc.).

Additionally, or alternatively, the security application may store thesecurity code in a memory associated with user device 210. In oneexample, the security application may store the security code in amanner that cannot be accessed by the subscriber and/or otherapplications that are stored on user device 210. Additionally, oralternatively, the security application may encode the security code(e.g., using a cryptographic hash function, an encryption function, ahash function, and/or some other mathematical function) in a manner thatprecludes the security code from being obtained except by the securityapplication.

As also shown in FIG. 5, process 500 may include outputting anout-of-band message that includes the security code and an identifierassociated with a subscriber (block 515). For example, user device 210may obtain an identifier, associated with the subscriber, such as theMDN and/or some other identifier. In the description below, theidentifier is described as being a MDN for explanatory purposes. Inanother implementation, another identifier, other than the MDN, may beused, such as, for example, a SIM URI, a MIN, an IMSI, a MSISDNidentifier, a NAI, etc.

User device 210 may output a message, to message server 260, thatincludes the security code and the MDN. In one example, user device 210may output the message as an out-of-band message based on a messageprotocol (e.g., an SMS MO protocol, a SS7 protocol, etc.). Messageserver 260 may receive the message and may provide the message toapplication server 270. In one example, message server 260 may use ashort code associated with application server 270 and/or some otherformat, to forward the out-of-band message to application server 270.Application server 270 may receive the out-of-band message and may, in amanner to be described in greater detail below with respect to FIG. 7,store the security code and/or the MDN in a data structure (e.g., datastructure 700 of FIG. 7) within database 280.

As further shown in FIG. 5, process 500 may include outputting a requestto access the service based on the security code and the identifier(block 520) and receiving a notification indicating whether thesubscriber is authenticated to access the service (block 525). Forexample, user device 210 may, as a result of outputting the out-of-bandmessage, use the security application to encode the security code. Thesecurity application may, for example, use an encoding mechanism (e.g.,a hash function, a cryptographic hash function, an encryption function,and/or some other mathematical function) and/or a copy of a key toencode the security code. User device 210 may also, or alternatively,provide a request, to application server 270, to access a service. Therequest may include the encoded security code and/or the MDN, and/or mayidentify the service to be accessed (e.g., from service provider 285,application server 270, or some other server). In one example, therequest may be provided using a protocol (e.g., HTTP, SMPP, SIP, etc.).Application server 270 may receive the request and may, in a manner thatis described in greater detail below with respect to FIG. 7, perform anauthentication operation on the subscriber based on the encoded securitycode and/or MDN received in the request and/or the security code and/orMDN stored in database 280. Authentication server 270 may, based on theauthentication operation, provide a notification, to user device 210,that indicates whether the subscriber is authenticated for use of theservice.

As yet further shown in FIG. 5, if access is not granted (block 530—NO),process 500 may include generating another security code (block 535).For example, user device 210 may receive, from application server 270, anotification that indicates whether the subscriber is authenticated.When the notification indicates that the subscriber is notauthenticated, user device 210 may not access the service. Additionally,or alternatively, user device 210 may execute the security applicationto generate another security code. User device 210 may also, oralternatively, use the other security code to authenticate thesubscriber in a manner similar to that described above with respect toblocks 515-525.

As still further shown in FIG. 5, if access is granted (block 530—YES),process 500 may include accessing the service (block 540). For example,user device 210 may receive, from application server 270, a notificationthat indicates that the subscriber is authenticated. In one example,application server 270 may provide the service to user device 210 whenthe subscriber is authenticated. Additionally, or alternatively,application server 270 may provide a notification, to service provider285, indicating that the subscriber is authenticated. Service provider285 may receive the notification and may provide the service to userdevice 210.

FIG. 6 is a diagram of an example data structure 600 that storesauthentication information associated with a subscriber. Data structure600 may be stored in database 280. As illustrated in FIG. 6, datastructure 600 may include a collection of fields, such as a sessionfield 605, a subscriber identifier (ID) field 610, a code field 615, anda time field 620. Fields 605-620, within data structure 600, areprovided for explanatory purposes. Additionally, or alternatively, theremay be additional fields, fewer fields, different fields, or differentlyarranged fields than are shown in FIG. 6.

Session field 605 may store information that identifies a sessionassociated with user device 210. For example, application server 270 mayreceive an out-of-band message, in a manner similar to that describedabove with respect to block 515 (FIG. 5), and may generate a sessionidentifier, associated with a particular session, with user device 210.Additionally, or alternatively, application server 270 may obtain asession identifier from the out-of-band message, and may store thesession identifier in session field 605.

Subscriber ID field 610 may store a subscriber identifier (e.g., a MDNand/or some other subscriber identifier) associated with a subscriber.For example, application server 270 may, in a manner similar to thatdescribed above with respect to block 515 (FIG. 5), obtain, from theout-of-band message associated with the particular session, a subscriberidentifier (e.g., MDN, etc.) and may store the subscriber identifier insubscriber ID field 610.

Code field 615 may store a security code associated with the particularsession. For example, application server 270 may, in a manner similar tothat described above with respect to block 515 (FIG. 5), obtain, fromthe out-of-band message associated with the particular session, asecurity code. Application server 270 may store the security code incode field 615.

Time field 620 may store information that identifies a time when theout-of-band message was received and/or a time when the security code isto expire. For example, application server 270 may determine a time whenthe out-of-band message was received and may store information thatidentifies the time in time field 620. Application server 270 may also,or alternatively, determine a future time, relative to the time when theout-of-band message was received, when the security code is to expire.Application server 270 may also, or alternatively, store informationthat identifies the future time in time field 620. Application server270 may store, in data structure 600, other authentication informationfor each session being processed by authentication server 270.

FIG. 7 is a flow chart of an example process 700 for authenticating asubscriber, using a security code, in response to a request to access aservice. In one example implementation, process 700 may be performed byapplication server 270. Additionally, or alternatively, some or all ofprocess 700 may be performed by a device or collection of devicesseparate from, or in combination with, application server 270. FIG. 8 isa diagram of an example signal flow between devices of an exampleportion 800 of environment 200. As illustrated in FIG. 8, exampleportion 800 may include user device 210, base station 220, SGW 230, PGW240, message server 260, application server 270, and service provider285. User device 210, base station 220, SGW 230, PGW 240, message server260, application server 270, and service provider 285 may include thefeatures described above in connection with one or more of FIGS. 2-4. Inthe description below, a portion process 700 of FIG. 7 will be describedwith references to example portion 800 of FIG. 8.

As shown in FIG. 7, process 700 may include receiving an out-of-bandmessage (block 705). Assume that user device 210 receives an instructionto access a service. Assume also, that user device 210, in response tothe instruction, uses a security application, provided in user device210, to generate a first security code in a manner similar to thatdescribed above with respect to block 510 (FIG. 5). User device 210 mayprovide an out-of-band message 805 (FIG. 8) to message server 260 thatincludes the first security code and a first identifier, associated withthe subscriber (e.g., a MDN). In one example, user device 210 mayprovide out-of-band message 805 using a message protocol (e.g., an SMSMO protocol, an SS7 protocol, etc.). Message server 260 may receiveout-of-band message 805 and may provide out-of-band message 810 (FIG. 8)to application server 270. In one example, message server 260 mayprovide out-of-band message 810 using the message protocol and/or someother message protocol. Additionally, or alternatively, message server260 may use a short code, associated with application server 270, toprovide out-of-band message 810 to application server 270. Applicationserver 270 may receive out-of-band message 810.

As also shown in FIG. 7, process 700 may include obtaining, from theout-of-band message, a first security code and a first identifierassociated with a subscriber (block 710) and storing the first securitycode and the first identifier (block 715). For example, applicationserver 270 may obtain, from out-of-band message 810, the first securitycode and the first identifier. Application server 270 may also, oralternatively, identify a time at which out-of-band message 810 wasreceived and may associate a session identifier with out-of-band message810. Application server 270 may also, or alternatively, store thesession identifier, the first identifier, the first security code,and/or the identified time in a data structure (e.g., data structure 600of FIG. 6).

As further shown in FIG. 7, process 700 may include receiving, from auser device, a request to access a service (block 720) and obtaining,from the request, a second encoded security code and a second identifierassociated with the subscriber (block 725). Assume that user device 210generates an encoded security code and provides a request 815 (FIG. 8)to application server 270 in a manner similar to that described abovewith respect to block 620 of FIG. 6. Request 815 may, in one example,identify a service that is to be obtained from application server 270.Request 815 may also, or alternatively, identify a service that is to beobtained from service provider 285. In this example, request 815 mayinclude information that identifies service provider 285, such as anaddress associated with service provider 285 (e.g., an IP address, auniform resource locator (URL), etc.) Request 815 may include a secondidentifier associated with the subscriber and/or the encoded securitycode. Application server 270 may receive request 815 and may obtain,from request 815, the encoded security code and/or the secondidentifier.

As yet further shown in FIG. 7, if the second identifier does not matchthe first identifier (block 730—NO), process 700 may include providing,to the user device, a notification indicating that access is not grantedfor the service (block 735). For example, application server 270 mayaccess database 280 to determine whether the second identifier matchesan identifier that is stored in database 280. When the second identifierdoes not match the first identifier and/or any of other identifiersstored within database 280, application server 270 may provide, to userdevice 210, a response 820 (FIG. 8) indicating that the subscriber couldnot be authenticated and/or that user device 210 cannot access theservice.

As still further shown in FIG. 7, if the second identifier matches thefirst identifier (block 730—YES), process 700 may include decoding theencoded security code to create a second security code (block 740) andretrieving the first security code associated with the first identifier(block 745). For example, application server 270 may obtain a decodingmechanism that corresponds to the second identifier received via request815 (FIG. 8). Application server 270 may use the decoding mechanism todecode the encoded security code to create a second security code. Inone example, the decoding mechanism may include a key that correspondsto a key that is used, by user device 210, to generate the encodedsecurity code.

Application server 270 may also, or alternatively, access database 280and may determine that the second identifier matches the firstidentifier that is stored in database 280. When the second identifiermatches the first identifier, application server 270 may retrieve, fromthe data structure, the first security code associated with the firstidentifier.

As also shown in FIG. 7, if the second security code does not match thefirst security code (block 750—NO), process 700 may include providing,to the user device, the notification indicating that access is notgranted for the service (block 735). For example, application server 270may determine whether the second security code matches the firstsecurity code. When the second security code does not match the firstsecurity code, application server 270 may not authenticate thesubscriber.

Additionally, or alternatively, application server 270 may determinewhether the first security code, retrieved from database 280, hasexpired based on information, retrieved from database 280, thatidentifies a time that the first security code expires. Applicationserver 270 may determine that a current time is after the time that thefirst security code expires. Based on the determination that the firstsecurity code has expired, application server 270 may not authenticatethe subscriber. When the second security code does not match the firstsecurity code and/or when the first security code has expired,application server 270 may provide, to user device 210, response 820indicating that the subscriber could not be authenticated and/or thatuser device 210 cannot access the service.

As further shown in FIG. 7, if the second security code matches thefirst security code (block 750—YES), process 700 may includeestablishing a communication session via which the service can beaccessed (block 755) and providing, to the user device, a notificationindicating that access is granted to the service (block 755). Forexample, application server 270 may determine that the second securitycode matches the first security code. When the second security codematches the first security code, application server 270 may authenticatethe subscriber. When the subscriber is authenticated, application server270 may, in one example, provide a service 825 (FIG. 8) to user device210.

Additionally, or alternatively, when the service is to be obtained fromservice provider 285, application server 270 may provide anauthentication service to service provider 285 that indicates whetherthe subscriber is authenticated. In this example, when the subscriber isauthenticated, application server 270 may provide an authenticationnotification 830 (FIG. 8), to service provider 285, that indicates thatthe subscriber is authenticated.

Additionally, or alternatively, when the subscriber is authenticated,application server 270 may cause a session to be established thatenables user device 210 to communicate with service provider 285, vianetwork 290, to access the service. For example, application server 270may provide a session request 835 (FIG. 8) to MME 235 requesting toestablish a session to enable user device 210 to access the service fromservice provider 285. MME 235 may receive session request 835 and mayprovide a set of bearer requests 840-1-840-3 to signal bearer devices,such as SGW 230, PGW 240, and/or base station 220, respectively. Bearerrequests 840 may cause the signal bearer devices to set up acommunication session that enables user device 210 to communicate withservice provider 285 via network 290. MME 235 may, based on establishingthe session, provide a session response 845 (FIG. 8) to applicationserver 270 indicating that the session has been established.

Application server 270 may receive session response 845 and may provide,to user device 210, a response 850 (FIG. 8) indicating that thesubscriber is authenticated and/or that the service can be obtained fromservice provider 285. User device 210 may receive response 850 and mayprovide, to service provider 285 and via the signal bearer devices,service request 855 (FIG. 8). Service request 855 may includeinformation that identifies the subscriber (e.g., the MDN, etc.) and/orthe service to be obtained by user device 210. Service provider 270 mayreceive service request 855 and may, based on authenticationnotification 830 that indicates that the subscriber is authenticated,provide a service 860 (FIG. 8) to user device 210.

Systems and/or methods, described herein, may enable a server device,such as an application server, to authenticate a subscriber based on asecurity code that is generated by a user device. The user device maygenerate the security code and may provide the security code to theapplication server via an out-of-band message. The user device may also,or alternatively, provide, to the application server, a request (e.g.,for a service) that includes an encoded version of the security code.Providing the security code, to the application server, via theout-of-band message and the encoded version of the security code via therequest, may enable the application server to authenticate thesubscriber for use of the service based on the security code and theencoded version of the security code.

The foregoing description provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above disclosure or may be acquired from practice of theembodiments.

While series of blocks have been described with regard to FIGS. 4, 5 and7, the order of the blocks may be modified in other implementations.Further, non-dependent blocks may be performed in parallel.

It will be apparent that systems and methods, as described above, may beimplemented in many different forms of software, firmware, and hardwarein the implementations illustrated in the figures. The actual softwarecode or specialized control hardware used to implement these systems andmethods is not limiting of the embodiments. Thus, the operation andbehavior of the systems and methods were described without reference tothe specific software code—it being understood that software and controlhardware can be designed to implement the systems and methods based onthe description herein.

Further, certain portions, described above, may be implemented as acomponent that performs one or more functions. A component, as usedherein, may include hardware, such as a processor, an applicationspecific integrated circuit (ASIC), or a field programmable gate array(FPGA), or a combination of hardware and software (e.g., a processorexecuting software).

It should be emphasized that the terms “comprises”/“comprising” whenused in this specification are taken to specify the presence of statedfeatures, integers, steps or components but does not preclude thepresence or addition of one or more other features, integers, steps,components or groups thereof.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the embodiments. In fact, many ofthese features may be combined in ways not specifically recited in theclaims and/or disclosed in the specification. Although each dependentclaim listed below may directly depend on only one other claim, thedisclosure of the embodiments includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used in the present application shouldbe construed as critical or essential to the embodiments unlessexplicitly described as such. Also, as used herein, the articles “a” and“an” are intended to include one or more items and may be usedinterchangeably with “one or more.” Where only one item is intended, theterm “one” or similar language is used. Further, the phrase “based on”is intended to mean “based, at least in part, on” unless explicitlystated otherwise.

What is claimed is:
 1. A user device comprising: one or more processorsto: receive an indication that a security code is to be generated,generate the security code based on the indication, generate a messagethat includes the security code and an identifier associated with asubscriber of the user device, output the message using the firstprotocol, encode the security code based on outputting the message,output a request to access the service, the request being outputtedusing a second protocol, and the request including the encoded securitycode and the identifier, receive a notification that indicates whetherthe subscriber is authenticated based on the identifier, the securitycode, and the encoded security code, and access the service when thenotification indicates that the subscriber is authenticated.
 2. The userdevice of claim 1, where the one or more processors are further to:generate a random value, and generate, using a first mechanism, thesecurity code based on at least one of: the random value, theidentifier, or a combination of the random value and the identifier. 3.The user device of claim 2, further comprising: generate, using a secondmechanism, the encoded security code based on the security code, thesecond mechanism corresponding to at least one of: a hash function, acryptographic hash function, or an encryption function.
 4. The userdevice of claim 1, where, when outputting the message using the firstprotocol, the one or more processors are further to: output, using thefirst protocol, the message to a first server device, outputting themessage to the first server device enabling the message to be providedto a second server device from which the service is to be obtained. 5.The user device of claim 4, where, when outputting the request using thesecond protocol, the one or more processors are further to: output,using the second protocol, the request to second server device,outputting the request to the second server device enabling the secondserver device to determine whether to authenticated the subscriber basedon the security code and the encoded security code.
 6. The user deviceof claim 1, where the one or more processors are further to: receive aninstruction to access another service, retrieve the security code from amemory, associated with the user device, based on the instruction,encode the security code to create the encoded security code, and outputanother request for the other service, the other request including theencoded security code and the identifier.
 7. The user device of claim 1,where the one or more processors are further to: receive a notificationindicating that the subscriber is not authenticated, generate adifferent security code based on the notification indicating that thesubscriber is not authenticated.
 8. The user device of claim 1, wherethe one or more processors are further to: output, using the firstprotocol, a different message the different message including theidentifier and a different security code, encode the different securitycode to create a different encoded security code, output, using thesecond protocol, a different request to access the service, thedifferent request including the different encoded security code and theidentifier, receive a different notification that indicates that thesubscriber is authenticated based on the identifier, the differentsecurity code, and the different encoded security code, and access theservice based on the different notification indicating that thesubscriber is authenticated.
 9. The user device of claim 1, where thefirst protocol is different than the second protocol, the first protocolcorresponding to at least one of: an instant message protocol; a shortmessage service (SMS) protocol, or a signal systems seven (SS7)protocol; and where the second protocol corresponds to at least one of:a hypertext transfer protocol (HTTP), a short message peer-to-peer(SMPP) protocol, or a session initiation protocol (SIP).
 10. A serverdevice, comprising: one or more processors to: receive messages thatinclude first identifiers and first codes, the first identifierscorresponding to subscribers, receive, from a user device, a request toaccess a service, the request including a second identifier and a secondcode, the second identifier corresponding to a subscriber, of thesubscribers, determine whether the second identifier matches a firstidentifier, of the first identifiers, decode the second code to create athird code, identify a first code, of the first codes, that correspondsto the first identifier when the second identifier matches the firstidentifier, determine whether the third code matches the first code,authenticate the subscriber when the third code matches the first code,and provide, to the user device, an indication that the user device isauthorized to access the service based on authenticating the subscriber.11. The server device of claim 10, where, when receiving the messages,the one or more processors are further to: receive, from the user deviceand via a particular server device, a first message, of the messages,the first message being based on a message protocol, obtain, from thefirst message, the first identifier and the first code, and store thefirst identifier and the first code in a memory associated with theserver device.
 12. The server device of claim 11, where the messageprotocol corresponds to at least one of: a short message service (SMS)protocol, a signal systems seven (SS7) protocol, or an instant messageprotocol.
 13. The server device of claim 10, where the one or moreprocessors are further to: determine that the subscriber is notauthenticated when the second identifier does not match the firstidentifier, and provide, to the user device, an indication that the userdevice is not authorized to access the service based on thedetermination that the subscriber is not authenticated.
 14. The serverdevice of claim 10, where the one or more processors are further to:determine that the subscriber is not authenticated when the third codedoes not match the first code, and provide, to the user device, anindication that the user device is not authorized to access the servicebased on the determination that the subscriber is not authenticated. 15.The server device of claim 10, where the one or more processors arefurther to: determine that the subscriber is not authenticated when thefirst code has expired, and provide, to the user device, an indicationindicating that the user device is not authorized to access the servicebased on the determination that the first code has expired.
 16. Theserver device of claim 10, where, when determining whether the secondidentifier matches the first identifier, the one or more processors arefurther to: access a memory, associated with the server device, toperform a lookup operation, the memory storing the first identifier andthe first codes, determine, based on the lookup operation, that thesecond identifier matches the first identifier of the stored firstidentifiers, and retrieve, from the memory, the first code thatcorresponds to the first identifier.
 17. A method comprising: receiving,by a user device, an indication that a first code is to be generated;generating, by the user device, the first code based on the indication;obtaining, by the user device, an identifier associated with asubscriber; providing, by the user device, the first code and theidentifier to a first server device based on a first protocol, the firstserver device providing a service, based on the first protocol, thatenables the code and the identifier to be provided to a second serverdevice; generating, by the user device and using a mechanism, a secondcode after providing the first code and the identifier to the firstserver device, the mechanism enabling the user device to encode thefirst code to create the second code; providing, by the user device andto the second server device, the second code and the identifier, thesecond code and the identifier being provided to the second serverdevice using a second protocol that is different than the firstprotocol; receiving, by the user device and from the second serverdevice, a notification that indicates whether the subscriber isauthenticated based on the identifier, the first code, and the secondcode; and accessing, by the user device, the service when thenotification indicates that the subscriber is authenticated.
 18. Themethod of claim 17, where the second code is encoded in a manner thatdoes not permit the first code to be used, by a different user device,to access the service.
 19. The method of claim 17, further comprising:receiving an instruction to access the service; retrieving, from thememory, the first code based on the instruction; encoding the first codeto create the second code; and providing, to the second server device,the second code and the identifier based on encoding the first code tocreate the second code.
 20. The method of claim 17, further comprising:receiving a notification that indicates that the subscriber is notauthenticated; generating a third code based on the notification thatthe subscriber is not authenticated; providing the third code and theidentifier to the first server device based on the first protocol;generating, using the mechanism, a fourth code based on the third code;providing, to the second server device and using the second protocol,the fourth code and the identifier after providing the third code andthe identifier to the first server device; receiving, from the secondserver device, a notification that indicates that the subscriber isauthenticated based on the third code, the fourth code, and theidentifier; and accessing the service when the notification indicatesthat the subscriber is authenticated.